Referring to FIG. 1, an example architecture 100 is shown. The architecture 100 conforms to an IEEE 802.15.4-2012 reference model or an LR-WPAN device architecture. The architecture 100 includes a physical (PHY) layer 102, a medium access control (MAC) layer 104, and upper layers 106. Upper layers may also be referred to herein as higher or high layers 106. Aspects of the architecture 100 are further described in IEEE Std 802.15.4-2012, “Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs),” which is incorporated by reference as if set forth in its entirety herein, and which is referred to herein as IEEE 802.15.4-2012. As shown, the architecture 100 includes four Service Access Points (SAPs) that have been defined for interactions between two layers. Specifically, the illustrated architecture 100 includes 1) a MAC Common Part Sublayer (MCPS) SAP 108 for data plane interactions between upper layers 106 and the MAC layer 104; 2) a MAC SubLayer Management Entity (MLME) SAP 110 for management plane interactions between upper layers 106 and the MAC layer 104; 3) a PD SAP 112 for data plane interactions between the MAC layer 104 and the PHY layer 102; and 4) a Physical Layer Management Entity (PLME) SAP 114 for management plane interactions between the MAC layer 104 and the PHY layer 102.
In IEEE 802.15.4-2012, service primitives are defined to realize a service, for example, by interacting between two protocol layers. Referring to FIG. 2, a primitive model 200 is shown as defined by IEEE. The primitive model 200 includes a first device 201a and a second device 201b. The first device 201a in the primitive model 200 makes a request, and thus the first device 201a can also be referred to as a Requestor 201a. The second device 201b in the primitive model 200 receives the request, and thus the second device 201b can also be referred to as a Recipient 201b. In accordance with the illustrated primitive model 200, one “Request” primitive 202 can result in: one “Confirm” primitive 204 at the same device (e.g., Requester 201a); and an “Indication” primitive 206 and a “Response” primitive 208 at the other device (e.g., Recipient 201b). The model 200 is referred to herein as a one-to-one primitive model. Still referring to FIG. 2, in accordance with the illustrated example, the request primitive 202 is used to request that a service is initiated. The indication primitive 206 is used to indicate an external event to the user of the second device 201b. The response primitive 208 is used to complete a procedure previously invoked by the indication primitive 206. The confirm primitive 204 is used to convey the results of one or more associated previous service requests.
IEEE 802.15.4-2012, which is incorporated by reference as if the disclosure of which is set forth in its entirety herein, defines the following types of services, and each type is realized via certain primitives: 1) MAC management service, which is realized via MLME SAP primitives; 2) MAC data service, which is realized via MCPS SAP primitives; 3) PHY management service, which is realized via PLME SAP primitives; and 4) PHY data service, which is realized via PD SAP primitives.
Table 1 below shows example MLME-SAP primitives that are specified in IEEE 802.15.4-2012, and Table 2 below shows example MCPS-SAP primitives that are specified in IEEE 802.15.4-2012.
TABLE 1Primitive NameDescriptionRequestIndicationResponseConfirmMLME-Used for a device to✓✓✓✓ASSOCIATEassociate with a WPANMLME-Used for a device to de-✓✓✓DISASSOCIATEassociate with a WPANMLME-To notify upper layer of a✓BEACON-received beaconNOTIFYMLME-COMM-To allow the MLME to✓STATUSindicate a communicationsstatusMLME-GETTo request information✓✓about a given PIB attributeMLME-GTSTo request and maintain✓✓✓GTSsMLME-Used by a coordinator to✓✓ORPHANissue a notification of anorphaned deviceMLME-RESETTo reset MAC sublayer✓✓MLME-RX-To enable or disable a✓✓ENABLEdevice's receiver at a giventimeMLME-SCANTo either find PANs in a✓✓channel or measure theenergy in the channelMLME-SETTo write PIB attributes✓✓MLME-STARTUsed by an FFD to initiate a✓✓PAN, to begin using a newsuperframe configuration,or to stop transmittingbeacons. In addition, adevice uses theseprimitives to begin using anew superframeconfigurationMLME-SYNCTo synchronize with a✓✓coordinator and tocommunicate loss ofsynchronization to the nexthigher layerMLME-SYNC-To indicate the loss of✓LOSSsynchronization with thecoordinator to the nexthigher layerMLME-POLLTo request data from the✓✓coordinatorMLME-DPSUsed by a device to enable✓✓✓or disable dynamicpreamble selection (DPS)as well as to define thevalue of dynamic preamblefor transmission andreception for a given time(only for UWB PHY)MLME-To obtain the results of a✓✓SOUNDINGchannel sounding from anRanging-capable Device(RDEV) that supports theoptional sounding capabilityMLME-To obtain the results of a✓✓CALIBRATEranging calibration requestfrom an RDEV
TABLE 2Primitive NameDescriptionRequestIndicationResponseConfirmMCPS-DATAUsed for a device to associate✓✓✓with a WPANMCPS-Used for a device to de-✓✓PURGEassociate with a WPAN
FIG. 3 shows an example reference model 300 proposed for IEEE 802.15.8. Referring to the example that is illustrated in FIG. 3, a PD Management Entity (PDME) 302 is defined, but it is recognized herein that current approaches, including the current PDME, have not addressed how to exchange various specific management information (e.g., context information). Further, it is recognized herein that there are no MAC/PHY primitives defined in the current approaches.